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Abstract 

We  present  an  improved  protocol  for  authenticating  Mo¬ 
bile  IPv6  connections ,  addressing  requirements  established 
in  the  relevant  Internet  Draft  [3],  The  protocol  imposes 
minimal  computational  requirements  on  mobile  nodes ,  uses 
as  few  messages  as  possible f  and  may  be  adapted  to  resist 
denial  of  service  attacks .  Our  protocol  has  two  parts ,  an 
initialization  phase  and  an  update  phase.  The  initialization 
phase  takes  advantage  of  available  authentication  infras¬ 
tructure  to  set  up  a  shared  secret  between  a  mobile  and  cor¬ 
respondent  node.  Each  execution  of  the  update  phase  uses 
the  shared  secret  established  in  the  previous  phase  to  main¬ 
tain  security  of  the  mobile  connection.  We  have  formally 
verified  the  correctness  of  the  protocol  using  the  finite-state 
analysis  tool  Munp ,  which  has  been  used  previously  to  an¬ 
alyze  hardware  designs  and  security  properties  of  several 
protocols. 


1.  Introduction 

In  Mobile  IPv6  [1],  a  mobile  node  has  two  associated 
IP  addresses.  A  mobile  node  is  always  identified  by  its 
home  address ,  While  operating  away  from  its  home,  a  mo¬ 
bile  node  is  also  associated  with  a  care-of  address,  which 
provides  information  about  its  current  location  on  the  inter¬ 
net  The  care-of  address  is  registered  with  the  home  agent, 
which  transparently  routes  IPv6  packets  sent  to  the  home 
address  to  the  care-of  address.  To  reduce  routing  distance 
and  relieve  the  load  on  home  agents,  a  mobile  node  may 
also  inform  other  IPv6  nodes  about  its  current  care-of  ad¬ 
dress.  The  need  for  authenticating  address  notification  mes¬ 
sages  has  been  recognized  [1,3].  While  providing  authen¬ 
tication,  any  proposed  solution  must  address  two  additional 
concerns:  (a)  computational  tasks  should  be  appropriately 
distributed  so  that  smaller  mobile  nodes  do  not  need  to  per¬ 
form  tasks  which  require  expensive  computations;  (b)  the 
available  authentication  infrastructure  may  be  limited  in  the 
sense  that  some  nodes  may  possess  public  key  certificates 
while  others  may  not  be  part  of  a  global  public  key  infras¬ 


tructure.  Previous  proposals  either  fall  short  of  meeting  the 
authentication  requirements  [1,  4,  5]  or  use  IPSec  thereby 
requiring  mobile  nodes  to  possess  public  key  certificates 
from  a  global  PKI  and  perform  expensive  computation  [2], 

In  this  paper,  we  present  a  protocol  for  authenticating  ad¬ 
dress  notification  messages  (or  binding  updates  in  Mobile 
IPv6  terminology),  taking  into  consideration  the  computa¬ 
tional  and  infrastructure  requirements.  Throughout,  we  use 
the  Mobile  IPv6  scenario  as  a  concrete  example.  We  em¬ 
phasize,  however,  that  the  proposed  protocol  would  be  ap¬ 
plicable  in  other  situations  where  mobile  devices  communi¬ 
cate  with  each  other.  In  particular,  cellular  phone  networks 
could  provide  another  useful  application  scenario. 

The  protocol  has  two  phases:  (a)  a  once-per-connection 
initialization  phase  in  which  a  mobile  node  and  a  corre¬ 
spondent  node  use  any  available  chain  of  trust  through  au¬ 
thentication  servers  in  their  respective  domains  to  confirm 
a  shared  secret;  (b)  an  update  phase  that  is  executed  every 
time  an  authenticated  address  notification  message  needs  to 
be  sent;  the  shared  secret  established  in  the  previous  phase 
is  used  as  the  basis  of  authentication.  The  protocol  provides 
sender  authentication,  data  integrity,  and  replay  protection, 
without  requiring  mobile  nodes  to  perform  public  key  oper¬ 
ations.  Using  a  forward  message  from  the  mobile  node  to 
the  correspondent  node,  and  a  reply  through  the  authentica¬ 
tion  servers  only  once  in  the  initialization  phase,  the  proto¬ 
col  minimizes  the  number  of  messages  exchanged  between 
participating  entities.  While  we  assume  that  mobile  and 
correspondent  nodes  share  a  secret  key  with  their  respec¬ 
tive  authentication  servers,  the  protocol  does  not  require  the 
servers  to  maintain  state  during  the  execution  of  the  pro¬ 
tocol,  avoiding  memory  denial-of-service  attacks  and  other 
resource  consumption  problems. 

An  important  idea  behind  the  protocol  is  to  use  symmet¬ 
ric  key  encryption  to  move  computation  involving  public 
keys  from  a  mobile  node  to  a  more  powerful  node  in  its  do¬ 
main.  Starting  from  an  IPSec-like  key  exchange  protocol 
in  which  a  mobile  node  and  a  correspondent  node  directly 
authenticate  each  other  using  public-key  cryptography,  we 
systematically  apply  protocol  transformations  to  finally  ar¬ 
rive  at  the  protocol  which  meets  the  desired  design  crite- 
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ria.  The  protocol  transformations  are  described  informally 
to  convey  the  intuition  behind  the  design.  A  complete  for¬ 
malization  of  protocol  transformation  rules  and  their  cor¬ 
rectness  will  be  presented  elsewhere. 

The  second  important  issue  is  that  of  limited  authenti¬ 
cation  infrastructure.  While  there  have  been  concrete  pro¬ 
posals  for  maintaining  a  global  trust  infrastructure,  e.g,,  by 
extending  the  Domain  Name  System  (see  [6, 7]),  successful 
deployment  in  the  short  term  seems  unlikely.  We  therefore 
consider  several  variants  of  public  key  certification  :  nodes 
can  obtain  certificates  from  a  trusted  Certification  Authority 
(CA);  they  can  use  cached  self-signed  certificates;  or  they 
can  obtain  certificates  online  from  a  nearby  server  where 
the  server  itself  might  possess  either  a  certificate  from  a 
CA  or  a  cached  self-signed  certificate.  As  an  expository 
convenience,  we  present  our  protocol  under  the  assumption 
that  each  authentication  server  has  a  public-key  certificate 
issued  by  a  CA.  The  strong  authentication  properties  dis¬ 
cussed  above  hold  under  this  assumption.  We  then  con¬ 
sider  scenarios  in  which  some  of  the  certificates  are  self- 
signed.  The  value  of  self-signed  certificates  is  that  the  first 
time  the  authentication  servers  participate  in  Mobile  IP,  they 
exchange  self-signed  certificates  and  cache  them.  In  subse¬ 
quent  executions  of  the  protocol,  they  use  the  cached  self- 
signed  certificates  for  authentication.  While  this  method  is 
susceptible  to  a  person-in-the-middle  attack,  an  attack  is 
only  possible  once  for  each  pair  of  authentication  servers 
(up  to  the  capacity  of  the  certificate  cache).  An  additional 
advantage  of  this  scheme,  which  could  make  a  difference 
during  its  implementation,  is  that  the  structure  of  the  pro¬ 
tocol  is  minimally  affected  by  the  available  authentication 
infrastructure  -  the  difference  merely  lies  in  the  nature  of 
the  certificates  used  and  how  they  are  obtained. 

The  design  of  security  protocols  has,  in  general,  been 
notoriously  prone  to  errors.  In  the  recent  past,  a  fruitful  ap¬ 
plication  of  formal  methods  has  been  in  uncovering  bugs 
and  proving  correctness  of  a  broad  class  of  security  proto¬ 
cols.  In  particular,  formal  methods  have  been  successfully 
used  to  analyze  key  exchange  and  authentication  protocols 
[8,  9,  10,  11,  12,  13].  We  have  formally  verified  the  cor¬ 
rectness  of  our  protocol  using  the  finite  state  analysis  tool 
Munp  [14].  In  previous  work,  Mur <p  has  been  used  to  verify 
the  correctness  of  several  protocols  [13,  15,  16,  17].  The 
fact  that  the  Mure/?  analysis  did  not  find  any  bugs,  therefore, 
gives  us  increased  confidence  in  the  correctness  of  die  pro¬ 
tocol. 

The  remainder  of  this  paper  is  structured  as  follows.  Sec¬ 
tion  2  describes  the  requirements  for  security  in  Mobile 
IPv6.  Section  3  briefly  discusses  the  previous  proposals  for 
authenticating  binding  updates.  In  Section  4,  we  present 
our  basic  protocol.  Section  5  presents  our  modelling  as¬ 
sumptions  and  analysis  results.  In  Section  6,  we  discuss 
extensions  to  prevent  denial  of  service  attacks.  Concluding 


remarks  appear  in  Section  7. 

2.  Security  Requirements  for  Address  Notifica¬ 
tion 

While  address  notification  makes  end-to-end  routes 
shorter,  the  ability  to  change  routes  on  the  fly  introduces  a 
number  of  security  concerns.  A  Mobile  IPv6  address  noti¬ 
fication  message  specifies  an  association  between  the  home 
address  of  a  mobile  node  and  its  care-of  address,  along  with 
the  remaining  lifetime  of  that  association.  Upon  receiving 
an  address  notification  message  from  a  mobile  node  (MN), 
a  correspondent  node  (CN)  stores  this  association.  Subse¬ 
quently,  the  CN  will  send  all  packets  destined  for  the  MN 
to  its  care-of  address  instead  of  its  home  address.  Threats 
and  security  requirements  for  address  notification  messages 
(or  binding  updates)  are  described  at  length  in  [3].  Here,  we 
discuss  the  most  pressing  security  issues. 

In  the  absence  of  a  pre-established  security  association 
between  MN-CN  pairs,  two  major  security  threats  arise: 

•  An  attacker  may  send  false  address  information  if 
binding  updates  are  not  authenticated.  In  fact,  an  ac¬ 
tive  attacker  can  launch  a  person-in-the-middle  attack, 
pretending  to  be  the  default  router  to  the  MN  and  the 
MN  to  the  CN. 

•  An  attacker  can  launch  denial-of-service  attacks  on 
MN’s,  CN’s  and  Home  Agents  (HA’s).  This  could  be 
done,  for  example,  by  flooding  IPv6  nodes  with  fake 
binding  updates. 

Our  main  goal  is  to  institute  a  mechanism  for  setting  up 
security  associations  between  MN-CN  pairs  that  will  allow 
binding  updates  to  be  authenticated.  Additional  require¬ 
ments,  as  specified  in  [3],  are: 

•  Identity  verification  should  not  rely  on  the  existence  of 
a  global  PKL 

•.Consider  the  computational  capabilities  of  the  MN’s 
and  CN's. 

•  Minimize  the  number  of  messages  and  bytes  sent  be¬ 
tween  the  participating  entities. 

•  Resist  denial-of-service  attacks. 

•  In  any  event,  provide  no  weaker  guarantees  than  IPv4. 

The  starting  point  for  our  investigation  of  authenticated 
binding  updates  is  the  realization  that  every  authentication 
protocol  relies  on  some  form  of  previously  established  au¬ 
thentication  infrastructure.  In  order  for  A  to  directly  authen¬ 
ticate  herself  to  B,  agent  A  must  be  able  to  perform  some 
action,  either  individually  or  in  collaboration  with  services 


“available  on  the  network,  that  can  only  be  performed  by  A 
and  that  B  is  able  to  recognize,  either  individually  or  in  col- 
•  laboration  with  services  available  on  the  network.  If  A  has 
a  public-private  key  pair  and  the  public  verification  key  is 
known  by  B  to  be  associated  with  A,  then  digital  signa¬ 
tures  allow  B  to  verify  a  claim  from  A.  Shared  symmetric 
keys,  shared  secret  hash  keys,  and  other  shared  secret  or  un- 
forgeable  information  can  also  be  used  for  authentication. 
In  effect,  the  infrastructure  must  provide  a  chain  of  trust 
from  A  to  B.  Our  goal  is  to  present  the  most  reliable  form 
of  authentication  possible  for  each  of  the  most  realistic  or 
potentially  achievable  chains  of  trust.  Further  discussion  on 
how  our  authentication  protocol  leverages  various  trust  in¬ 
frastructures  appears  in  Section  4. 

3.  Previous  Proposals 

Previous  protocols  for  authenticating  binding  updates 
[1,  2,  4,  5]  fall  short  of  meeting  all  the  security  require¬ 
ments.  We  review  these  protocols  to  show  some  of  the 
forms  of  cryptography  that  have  been  considered  and  to  il¬ 
lustrate  their  shortcomings. 

An  earlier  version  of  the  Mobile  IPv6  Internet  Draft  [2] 
advocated  the  use  of  IPSec  and  IKE  [18]  to  authenticate 
binding  updates.  Although  this  approach  provides  strong 
authentication,  it  suffers  from  two  serious  drawbacks.  It  re¬ 
quires  mobile  nodes  to  possess  public  key  certificates  from 
a  global  PKI  and  to  perform  expensive  public-key  crypto¬ 
graphic  operations. 

In  contrast,  the  current  Mobile  IPv6  Internet  Draft  [1] 
offers  a  solution  at  the  other  end  of  the  spectrum.  The 
“return  routability  procedure”  proposed  there  does  not  rely 
on  any  form  of  authentication  infrastructure.  The  mobile 
node  sends  two  cookies  to  the  correspondent  node:  the  HoT 
cookie  and  the  CoT  cookie.  The  correspondent  node  returns 
the  HoT  cookie  to  the  mobile  node's  home  address  and  the 
CoT  cookie  to  its  care-of  address.  In  addition  it  generates 
two  additional  cookies  of  its  own  -  the  home  cookie  and 
the  care-of  cookie  and  sends  them  to  the  mobile  node.  The 
home  cookie  is  sent  with  the  HoT  cookie  and  the  care-of 
cookie  with  the  CoT  cookie.  The  binding  update  is  cryp¬ 
tographically  bound  to  the  cookies  generated  by  the  corre¬ 
spondent  node.  A  correspondent  node  therefore  authenti¬ 
cates  a  mobile  node  by  verifying  whether  it  is  reachable  at 
both  its  home  and  care-of  addresses.  However,  an  active 
attacker  on  the  path  between  the  mobile  node  and  the  cor¬ 
respondent  node  or  between  the  home  agent  and  the  corre¬ 
spondent  node  can  launch  a  person- in-the-middle  attack  on 
this  protocol. 

Bradner,  Mankin  and  Schiller  [4]  proposed  a  framework 
called  Purpose  Built  Keys .  Before  initiating  a  connection 
with  a  correspondent  node  (CN),  a  mobile  node  (MN)  gen¬ 
erates  a  public-private  key  pair  (called  a  purpose-built  key 


pair)  for  use  during  the  connection.  The  MN  then  sends 
a  hash  of  the  public  key  to  CN.  Subsequently,  when  MN 
sends  a  binding  update,  MN  signs  it  with  its  private  key  and 
also  sends  the  public  key  to  CN.  CN  verifies  that  the  public 
key  hashes  to  the  same  value  it  had  received  before  and,  if 
so,  uses  the  public  key  to  verify  the  digital  signature.  An  ad¬ 
vantage  of  this  framework  is  that  it  does  not  require  any  se¬ 
curity  infrastructure.  However,  purpose-built  keys  provide 
authentication  if  and  only  if  the  initial  hash  of  the  public 
key  is  received  correctly  by  CN.  This  might  not  be  the  case. 
An  attacker  could  intercept  the  hash  and  send  the  hash  of 
a  different  key  (which  it  owns)  to  CN.  Subsequently,  it  can 
pretend  to  be  MN  without  CN  being  any  wiser.  The  authors 
of  the  draft  were,  of  course,  aware  of  this  weakness. 

Le  and  Faccin  [5]  propose  two  protocols  for  authenti¬ 
cating  binding  updates.  The  first  assumes  that  both  the 
MN  and  the  CN  share  security  associations  with  two  AAA 
servers  (e.g.,  RADIUS  [19],  DIAMETER  [20])  and  these 
two  servers  in  turn  share  a  security  association.  The  proto¬ 
col  then  uses  this  chain  of  trust  to  achieve  authentication. 
Our  protocol  uses  a  similar  architecture  and  can  be  easily 
adapted  to  work  within  a  AAA  infrastructure.  Furthermore, 
it  employs  fewer  messages  than  Le  and  Faccin ’s  protocol  ( 
5  as  opposed  to  7).  This  improvement  is  obtained  by  com¬ 
bining  encryption-based  and  signature-based  authentication 
techniques  and  will  be  elaborated  further  in  the  next  sec¬ 
tion.  The  second  protocol  proposed  in  [5]  involves  an  unau¬ 
thenticated  Diffie-Hellman  key  exchange  between  MN  and 
CN.  The  resulting  key  is  subsequently  used  to  authenticate 
binding  updates.  The  authors  recognize  that  this  protocol  is 
vulnerable  to  a  man-in-the-middle  (MITM)  attack  but  state 
that  “due  to  the  properties  of  IP”  such  an  attack  will  always 
be  detected.  They  argue  that  since  an  attacker  cannot  re¬ 
move  any  packets  from  the  network,  if  a  MITM  attack  is 
launched,  both  the  MN  and  the  CN  will  receive  two  Diffie- 
Hellman  exponentials  and  will  therefore  be  able  to  detect 
the  attack.  There  are  a  couple  of  objections  to  this  argu¬ 
ment,  Firstly,  an  attacker  could  remove  packets  from  the 
network,  e.g.,  if  it  gained  control  of  the  router  being  used 
by  MN.  Secondly,  even  if  it  were  not  able  to  remove  pack¬ 
ets  from  the  network,  it  could  delay  them,  e.g.,  by  flooding 
MN  and  CN’s  network  buffers  with  junk  packets.  During 
that  interval,  it  could  potentially  cause  damage.  Also,  even 
if  MN  and  CN  detect  the  attack,  the  only  thing  they  can  do 
is  drop  the  session,  since  there  is  no  way  to  determine  which 
of  the  exponentials  is  authentic.  So,  the  attack  still  succeeds 
as  a  denial  of  service  attack. 

4.  The  Protocol 

In  this  section,  we  propose  a  specific  protocol  for  au¬ 
thenticating  binding  updates.  Our  protocol  consists  of  two 
phases:  (a)  an  initialization  phase  in  which  mobile  node 


( MN )  and  correspondent  node  (CN)  set  up  an  authentica¬ 
tion  key;  (b)  an  update  phase  in  which  MN  sends  an  au¬ 
thenticated  binding  update  to  CN  using  the  key  obtained 
from  phase  (a).  The  initialization  phase  protocol  is  pre¬ 
sented  in  stages.  Starting  from  an  IPSec-like  key  exchange 
protocol  in  which  a  mobile  node  and  a  correspondent  node 
directly  authenticate  each  other  using  public-key  cryptog¬ 
raphy,  we  systematically  apply  protocol  transformations  to 
finally  arrive  at  the  protocol  which  meets  the  design  crite¬ 
ria.  The  protocol  transformations  aim  at  moving  expensive 
computations  away  from  mobile  nodes  as  well  as  reducing 
the  reliance  on  authentication  infrastructure. 

Throughout,  we  assume  that  each  mobile  node  has  a  pre- 
established  bidirectional  security  association  with  an  au¬ 
thentication  server  in  its  domain.  This  is  a  reasonable  as¬ 
sumption  and  has  been  recognized  as  such  in  [3].  A  mo¬ 
bile  node’s  authentication  server  may  be  co-located  with  its 
home  agent  or  could  operate  independently.  We  also  as¬ 
sume  that  the  authentication  servers  are  capable  of  authen¬ 
ticating  each  other  using  public  key  cryptography.  Strong 
authentication  is  provided  if  the  public-key  certificates  are 
issued  by  a  CA;  weaker  authentication  guarantees  are  of¬ 
fered  if  some  of  the  certificates  are  self-signed. 

4,1  Notation 


The  following  notation  is  used  in  describing  the  protocol, 
MN  Mobile  node 

CN  Correspondent  node 

Am n  Authentication  server  of  MN 

Ac n  Authentication  server  of  CN 

B U  Binding  update 

Km  Shared  secret  between  M N  and  A m n 

Kc  Shared  secret  between  CN  and  Aqn 

K^{  Public  encryption  key  of  Amn 

N  Public  encryption  key  of  MN 

C ert{  Certificate  of  entity  i 

Sigi  { , » ,}  Signed  by  entity  i 

{. .  ,}a'  Encrypted  with  key  K 

[a?]  x  is  an  optional  parameter 

I  Pi  IP  (home)  address  of  i 

K o  Shared  Diffie-Heliman  secret  key 

h(k,  M)  Keyed  hash  of  message  M  with  key  k 

MAC(k){M}  Message  auth  code  of  M  with  key  k 


4.2  Protocol  Description 


4.2.1  Initialization  Phase 

The  base  two  party  protocol  from  which  we  derive  the  ini¬ 
tialization  phase  protocol  is  shown  in  Figure  1,  It  is  an  au¬ 
thenticated  Diffie-Heliman  key  exchange  protocol  [21,  24] 
resulting  in  a  shared  secret  between  MN  and  CN. 


MN  ->  CN  :  gx ,  [< CertMN ) 

CN  -4  MN  :  {«*}*+„»  SigcN  ( 9y ,  $*,  MN), 
[< OertcN ] 

MN  -4  CN  :  MAC(KD){f ,  CN} 

Figure  1.  Base  two  party  protocol 


The  first  message  is  straightforward.  Note  that  it  as¬ 
sumes  that  MN  already  knows  a  group  and  generator  that 
is  acceptable  to  CN.  Upon  receiving  that  message,  CN 
generates  gy  and  computes  Kb  —  gxy*  She  then  sends  gy 
encrypted  with  MNfs  public  key.  This  ensures  that  no  at¬ 
tacker  can  observe  gy .  The  signature  on  the  second  mes¬ 
sage  assures  MN  that  CN  did  in  fact  receive  gx,  generate 
gy  and  that  the  message  is  meant  for  MN.  Omitting  MN*s 
identity  from  inside  the  signature  opens  up  the  protocol  to 
a  person-in-the-middle  attack  similar  to  the  attack  on  the 
original  Needham-Schroeder  protocol  [22].  For  the  purpose 
of  this  protocol,  MN's  identity  could  be  its  home  address. 
In  the  third  message,  MN  sends  a  keyed  message  authen¬ 
tication  code  (e.g.,  HMAC  [25])  of  gx  and  CNfs  identity. 
The  key  is  the  Diffie-Heliman  secret  resulting  from  the  ex¬ 
change.  Since  only  MN  could  have  recovered  gv  and  com¬ 
puted  Kb,  CN  can  conclude  that  the  message  was  indeed 
sent  by  MN.  Including  gx  and  CNfs  identity  inside  the 
MAC  assures  CN  that  MN  had  sent  the  original  gx  and 
that  CN  is  the  intended  recipient  of  this  message. 

However,  this  protocol  fails  to  meet  the  design  require¬ 
ments  on  two  counter  it  requires  mobile  nodes  to  be  part  of 
a  global  PKI  as  well  as  to  perform  expensive  public-key  op¬ 
erations,  We  now  describe  a  protocol  transformation  mech¬ 
anism  aimed  at  overcoming  these  limitations.  The  idea  is  to 
introduce  another  protocol  principal,  Amn*  between  CN 
and  MN.  Instead  of  sending  authenticated  data  directly  to 
M N,  CN  sends  it  to  Am n  »  who  in  turn  forwards  it  to  MN. 
In  effect,  the  second  message  of  the  protocol  in  Figure  1 
gets  replaced  by  two  messages  -  one  from  CN  to  Amn  and 
the  next  from  Amn  to  MN.  Public-key  cryptography  is 
restricted  to  the  CN  - Amn  link.  Symmetric-key  cryp¬ 
tography  is  used  between  Amn  and  MN.  The  resulting 
protocol  is  shown  in  Figure  2. 

The  guarantees  provided  by  the  second  message  of  the 
base  protocol  in  Figure  1  are  preserved  by  the  second  and 
third  message  of  the  protocol  in  Figure  2.  Both  these  mes¬ 
sages  (a)  preserve  the  secrecy  of  gy;  (b)  authenticate  both 
gy  and  gx\  and  (c)  include  the  intended  recipient  of  the 
message  within  the  authenticated  data.  Note  that  the  second 
message  includes,  within  the  body  of  the  authenticated  data, 
the  component  {Amn,  MN}.  Along  with  the  intended  re¬ 
cipient  of  the  message,  this  component  specifies  the  path 


CN  ->  Amn  *  {Amn,MN}}k+  i 

M 

SigcN{gy,  gx,  {AMn,MN}}, 
[CertcN] 

Amn^MN:{9v,9*,MN}Km 

MN  -¥  CN  :  MAC(KD){gx,  CN } 

Figure  2.  Protocol  with  one  forwarding  agent 

along  which  the  authenticated  data  is  to  be  subsequently  for¬ 
warded.  It  can  be  viewed  as  a  generalization  of  the  scenario 
in  the  base  protocol  in  which  the  intended  recipient  does  not 
need  to  forward  the  data  to  another  principal. 

In  general,  a  correspondent  node  (CN)  can  either  be  a 
stationary  or  a  mobile  IPv6  node.  If  it  is  a  stationary  node 
with  sufficient  computational  power,  it  can  very  well  per¬ 
form  the  public-key  operations  required  in  the  protocol  of 
Figure  2.  However,  if  it  possesses  limited  computational  re¬ 
sources  or  if  it  does  not  have  a  public  key  certificate  whereas 
some  other  server  in  its  administrative  domain  does,  then  it 
would  be  useful  to  forward  the  second  message  of  the  pro¬ 
tocol  in  Figure  2  through  that  server  to  Am n  *  The  resulting 
protocol  is  shown  in  Figure  3. 

MN  -4  CN  :  gx,  [« CertAMN ] 

CN  -4  Acn  {9y,  gx,  {Acn,Amn,MN}}kCi 
[CertAMN  ] 

Acn  ->  Amn  ■  {9V,  gx,  {Amn,MN}}k+  , 

SWaCn{9Vi  9Xi  {^Miv,  MN}}, 
\CertAcN ] 

Amn  MN  :  { gv ,  gx ,  MN}km 

MN  ->  CN  :  MAC(KD){gx ,  CN} 

Figure  3.  Protocol  with  two  forwarding  agents 

As  before,  gy  is  sent  encrypted  throughout  and  gy,  gx, 
and  the  forwarding  paths  are  included  within  the  body  of 
the  authenticated  data.  Symmetric-key  cryptography  is  used 
between  CN  and  Acn-  Note  that  whether  CN  sends  the 
message  to  Amn  directly  or  through  Aqn  the  format  of 
the  message  is  exactly  die  same.  So,  based  on  the  available 
computational  power  and  authentication  infrastructure,  CN 
can  locally  decide  which  version  of  the  protocol  to  imple¬ 
ment  without  in  any  way  affecting  either  MN  or  Amn * 


Public-key  Certificates.  An  issue  that  merits  discussion  at 
this  point  is  the  nature  of  the  public-key  certificates  used 
and  how  they  are  obtained.  Two  of  the  protocol  principals 
(CN  or  Acn  and  Amn)  must  possess  public-key  certifi¬ 
cates.  Ideally,  both  of  these  certificates  would  be  issued 
by  a  globally  trusted  CA  or  a  chain  of  issuers  ending  at 
a  CA.  In  that  case,  after  executing  the  protocol  both  MN 
and  CN  are  guaranteed  that  they  share  a  secret  key  with 
each  other.  However,  in  the  absence  of  CA-issued  certifi¬ 
cates,  one  or  both  of  the  certificates  could  be  self-signed. 
In  that  case,  the  principals  will  exchange  the  certificates  the 
first  time  they  execute  the  protocol  and  cache  them  for  sub¬ 
sequent  use.  Self-signed  certificates  can  be  created  by  a 
node  for  herself  or  it  could  be  obained  online  from  a  nearby 
server  which  owns  a  certificate  (either  from  a  CA  or  self- 
signed).  How  certificates  are  obtained  is  thus  a  matter  of 
local  administrative  policy.  The  viability  of  caching  unau¬ 
thenticated  certificates  has  been  tested  by  SSH  and  seems  to 
work  quite  well  in  practice. 

Based  on  the  nature  of  the  certificates,  the  protocol  pro¬ 
vides  different  authentication  guarantees.  Three  possible 
cases  arise:  (a)  CN  (or  Aqn)  uses  a  self-signed  certificate 
while  Amn  uses  a  CA-issued  certificate.  In  that  case,  upon 
receiving  the  last  message  of  the  protocol,  CN  is  assured 
that  it  has  a  shared  secret  with  MN.  However,  MN  comes 
to  the  same  conclusion  only  under  the  assumption  that  the 
first  time  the  protocol  was  executed  with  that  CN,  a  person- 
in-the-middle  attack  was  not  launched.  In  any  case,  even 
if  MN  sets  up  a  shared  secret  with  a  node  impersonating 
CN,  authentication  is  not  compromised.  Since  CN  does 
not  know  the  secret,  it  will  reject  binding  updates  authenti¬ 
cated  with  it.  This  results  in  longer  routes  through  the  mo¬ 
bile  node’s  home  agent.  But  the  attacker  cannot  fool  CN 
into  accepting  a  fake  binding  update  by  pretending  to  be 
MN.  (b)  Amn  has  a  self-signed  certificate  while  CN  (or 
Aqn)  has  a  CA-issued  certificate.  In  that  case,  the  first  time 
CN  executes  the  protocol  with  MN,  it  is  possible  for  an  at¬ 
tacker  to  set  up  a  shared  secret  with  CN  by  pretending  to 
be  MN.  It  can  subsequently  fool  CN  into  accepting  bind¬ 
ing  updates  authenticated  with  the  shared  secret,  (c)  Both 
Amn  and  CN  (or  Acn)  have  self-signed  certificates.  As 
in  case  (b),  an  attacker  can  set  up  a  secret  with  CN  pretend¬ 
ing  to  be  MN  and  then  fool  her  into  accepting  fake  binding 
updates  authenticated  with  that  key.  In  addition,  as  in  case 
(a),  an  attacker  can  set  up  a  shared  key  with  MN  pretend¬ 
ing  to  be  CN.  However,  as  discussed  above,  this  does  not 
result  in  a  compromise  of  the  authentication  requirement. 
Indeed  for  the  purpose  of  authenticating  binding  updates,  it 
is  sufficient  if  Amn  possesses  a  CA-issued  public-key  cer¬ 
tificate.  However,  unless  CN  (or  Acn)  also  possesses  a 
similar  certificate,  the  protocol  is  open  to  denial-of-service 
attacks.  This  issue  is  discussed  further  in  Section  6. 

A  possible  instantiation  of  the  concept  of  self-signed  cer- 


tificates  is  CAM  [26].  When  a  mobile  CAM  node  is  first 
initialized,  she  creates  a  public-private  key  pair.  It  next 
chooses  a  home  address  for  Itself.  The  routable  64— bit 
address  prefix  is  obtained  by  listening  for  local  router  ad¬ 
vertisements.  The  lower-order  64  bits  are  chosen  to  coin¬ 
cide  with  a  cryptographic  one-way  hash  of  the  node’s  public 
key.  Upon  receiving  a  binding  update  signed  with  the  mo¬ 
bile  node’s  private  key,  the  correspondent  node  can  verify 
that  the  mobile  node’s  public  key  does  indeed  hash  to  the 
lower  order  bits  of  her  IPv6  address.  In  our  protocol,  a  sim¬ 
ilar  approach  can  be  adopted  for  binding  CNls  or  Aq^s 
public  keys  to  their  IP  addresses  if  they  are  in  a  position  to 
choose  the  lower  order  bits  of  their  IPv6  address. 

Minimizing  Number  of  Messages.  In  this  protocol,  CN 
authenticates  herself  to  MN  through  the  chain  of  trust  CN 
Aqn  Amn  MN.  MN  could  also  use  the  same 
trust  chain  in  the  other  direction  to  authenticate  herself  to 
CN.  This  would  lead  to  a  7-message  protocol  similar  to 
the  one  presented  in  [5].  In  order  to  reduce  the  number  of 
messages  to  5,  we  use  a  different  technique.  CN!  s  Diffie- 
Hellman  exponential  is  never  sent  in  the  clear;  it  is  sent  en¬ 
crypted  along  the  trust  chain  and  the  very  fact  that  MN 
is  able  to  recover  it  and  compute  the  same  Diffie-Hellman 
secret  as  CN  serves  to  verify  her  identity.  We  thus  com¬ 
bine  the  two  standard  techniques  of  signature-based  and 
encryption-based  authentication  to  realise  a  protocol  with 
fewer  messages.  The  difference  in  the  number  of  messages 
exchanged  in  the  two  protocols  becomes  more  appreciable 
as  the  trust  chain  becomes  longer.  If  there  are  n  participants, 
our  protocol  requires  n  + 1  messages  while  the  previous  ap¬ 
proach  requires  2n  —  1.  It  also  appears  that  we  can  do  no 
better.  Specifically,  any  Diffie-Hellman  based  authenticated 
key  exchange  protocol  P  between  entities  A  and  B  that  uses 
a  chain  of  trust  of  length  n  requires  at  least  n  + 1  messages. 

Perfect  Forward  Secrecy.  The  use  of  Diffie-Hellman  key 
exchange  ensures  that  the  protocol  provides  perfect  forward 
secrecy  (PFS),  i.e.,  the  disclosure  of  long-term  secrets  like 
private  signing/decryption  keys  does  not  compromise  the 
secrecy  of  exchanged  keys  from  earlier  runs.  However,  if 
perfect  forward  secrecy  is  not  a  requirement,  an  alternative 
would  be  to  replace  the  exchange  of  DH  exponentials  by  an 
exchange  of  nonces  (umn  and  ucn)-  ^mn  could  be  sent  in 
the  clear  in  message  1,  while  ucn  is  sent  encrypted  in  mes¬ 
sage  2, 3, 4.  The  shared  secret  could  be  derived  from  a  hash 
of  these  nonces,  e.g.,  HMAC(n^fiv*  ticn)  (see  [25]).  Note 
that  this  variation  of  the  base  protocol  does  not  have  PFS 
since  the  compromise  of  long  term  secrets  like  the  shared 
key  between  MN  and  Amn  exposes  all  past  ucn  val¬ 
ues  and  hence  all  past  session  keys.  The  advantage  is  that 
it  is  computationally  very  lightweight:  mobile  nodes  have 
to  perform  relatively  inexpensive  operations  -  generating  a 
random  nonce  and  computing  a  hash  instead  of  exponentia¬ 
tion. 


Other  Issues.  Typically,  in  order  to  prevent  replay  attacks, 
key  exchange  protocols  require  each  participant  to  use  some 
fresh  information  in  every  run  of  the  protocol.  The  Diffie- 
Hellman  exponentials  serve  this  purpose  in  our  protocol. 
We  would  also  like  to  note  here  that  an  implicit  assumption 
in  our  protocol  is  that  it  is  possible  to  verify  whether  an  au¬ 
thentication  server  actually  owns  a  node  which  it  claims  as 
its  own  (e.g.,  by  matching  the  network  prefix  of  the  home 
address  of  the  mobile  node  with  that  from  the  authentica¬ 
tion  server’s  certificate).  Otherwise,  the  protocol  is  open  to 
attack.  Any  adversary  which  possesses  a  certificate  could 
intercept  message  1  and  then  send  message  3  without  Amn 
being  any  wiser.  Of  course,  the  use  of  signatures  does  pro¬ 
vide  non-repudiation:  if  the  exchange  is  recorded  Amn  can 
prove  later  that  the  adversary  claimed  ownership  of  a  node 
that  it  in  fact  did  not  own. 

We  also  assume  that  the  signature  scheme  is  such  that  no 
information  regarding  plaintext  data  can  be  deduced  from 
the  signature  itself  on  that  data  (e.g.,  when  the  signature 
operation  involves  preliminary  one-way  hashing).  This  is 
critical  because,  in  general,  data  may  be  recovered  from  a 
signature  on  it  (e.g.,  RSA  without  hashing).  An  alternative 
approach  would  be  to  include  the  signed  block  inside  the 
public  key  encryption.  A  disadvantage  of  this  method  is 
that  here  the  data  to  be  public-key  encrypted  is  larger.  This 
might  require  adjustment  of  the  block-size  of  the  public  en¬ 
cryption  scheme  or  the  use  of  techniques  like  cipher-block- 
chaining  (see  Section  12.5.2  of  [23]  for  further  discussion 
on  the  relative  advantages  of  the  two  methods). 

4.2.2  Update  Phase 

Once  MN  and  CN  have  set  up  a  shared  secret,  ify?,  MN 
can  easily  send  an  authenticated  binding  update  ( BU )  by 
executing  the  following  1-message  protocol. 

BUMKd.BU) 

Here,  h(. . .)  is  a  keyed  cryptographic  hash  function  (e.g., 
HMAC  [25]).  This  protocol  provides  sender  authentication 
since  MN  is  the  only  entity  other  than  CN  which  possesses 
the  key  Kd*  Data  integrity  is  also  provided  since  the  hash 
is  also  a  message  authentication  code  (MAC).  Replay  at¬ 
tacks  can  be  prevented  by  using  the  sequence  number  field 
in  the  binding  update  option  (see  Section  5.1  of  [2]).  The 
sequence  number  field  holds  an  8-bit  number.  Each  binding 
update  sent  by  a  mobile  node  must  use  a  sequence  number 
which  is  greater  than  the  sequence  number  of  the  previous 
binding  update  sent  to  the  same  destination  address.  Every 
time  the  sequence  number  space  is  exhausted,  the  shared 
key  should  be  refreshed.  Key  refresh  could,  of  course,  be 
done  by  re-executing  the  initialization  phase  protocol.  Al¬ 
ternatively,  MN  and  CN  could  set  up  a  new  key  by  execut¬ 
ing  an  authenticated  Diffie-Hellman  key  exchange  protocol 


in  which  they  can  use  the  old  key  to  authenticate  messages* 
This  approach  would  require  the  home  agents  to  be  involved 
in  only  the  initialization  phase  (once  per  (MN,CN)  pair) 
and  the  system  would  scale  up  better. 

5.  Analysis  of  the  Protocol 

We  used  Murc^,  a  finite-state  analysis  tool,  to  carry  out 
a  formal  analysis  of  the  initialization  phase  of  our  protocol. 
In  this  section,  we  briefly  outline  the  general  methodology 
and  describe  some  of  the  challenges  we  faced  in  applying  it 
to  this  protocol.  A  general  description  of  the  methodology 
can  be  found  in  [13], 

5.1  The  Munp  Verification  System 

Mur xp  [14]  is  a  finite-state  verification  tool  that  has  been 
successfully  applied  to  multiprocessor  cache  coherence  pro¬ 
tocols  and  multiprocessor  memory  models  [27,  28],  The 
purpose  of  finite-state  analysis  (also  called  model  checking) 
is  to  exhaustively  search  all  possible  execution  sequences. 
While  this  process  often  reveals  errors,  failure  to  find  errors 
does  not  imply  that  the  protocol  is  completely  correct,  be¬ 
cause  the  Mur ip  model  may  simplify  certain  details  and  is 
inherently  limited  to  configurations  involving  a  small  num¬ 
ber  of  protocol  participants. 

To  use  Mxxrif  for  verification,  one  has  to  model  the  pro¬ 
tocol  in  the  Mury?  language  and  augment  this  model  with 
a  specification  of  the  desired  properties.  The  Mur^?  system 
automatically  checks,  by  explicit  state  enumeration,  if  all 
reachable  states  of  the  model  satisfy  the  given  specification. 
For  the  state  enumeration,  either  breadth-first  or  depth-first 
search  can  be  selected.  Reached  states  are  stored  in  a  hash 
table  to  avoid  redundant  work  when  a  state  is  revisited.  The 
memory  available  for  this  hash  table  typically  determines 
the  largest  tractable  problem. 

The  Mur^  language  is  a  simple  high-level  language  for 
describing  non-deterministic  finite-state  machines.  Many 
features  of  the  language  are  familiar  from  conventional  pro¬ 
gramming  languages.  The  main  features  not  found  in  typi¬ 
cal  high-level  programming  languages  are  described  in  the 
following  paragraphs. 

The  state  of  the  model  consists  of  the  values  of  all  global 
variables.  In  the  startstate  statement,  initial  values  are  as¬ 
signed  to  global  variables.  The  transition  from  one  state 
to  another  is  performed  by  rules.  Each  rule  has  a  Boolean 
condition  and  an  action,  which  is  a  program  segment  that  is 
executed  atomically.  The  action  may  be  executed  if  the  con¬ 
dition  is  true  (i.e.,  die  rule  is  enabled)  and  typically  changes 
global  variables,  yielding  a  new  state.  Most  Mur^  models 
are  nondeterministic  since  states  typically  allow  execution 
of  more  than  one  rule.  For  example,  in  the  model  of  our 


authentication  protocol,  the  intruder  (which  is  part  of  the 
model)  usually  has  the  choice  of  several  messages  to  replay. 

Mur^  has  no  explicit  notion  of  processes .  Nevertheless  a 
process  can  be  implicitly  modeled  by  a  set  of  related  rules. 
The  parallel  composition  of  two  processes  is  simply  done 
by  taking  the  union  of  the  rules  of  the  two  processes.  Each 
process  can  take  any  number  of  steps  (actions)  between  the 
steps  of  the  other.  The  resulting  model  is  that  of  asyn¬ 
chronous,  interleaving  concurrency . 

The  Mur^  language  supports  scalable  models.  In  a  scal¬ 
able  model,  one  is  able  to  change  the  size  of  the  model  by 
simply  changing  constant  declarations.  When  developing 
protocols,  one  typically  starts  with  a  small  protocol  config¬ 
uration.  Once  this  configuration  is  correct,  one  gradually 
increases  the  protocol  size  to  the  largest  value  that  still  al¬ 
lows  verification  to  complete.  In  many  cases,  an  error  in 
the  general  (possibly  infinite  state)  protocol  will  also  show 
up  in  a  down-scaled  (finite  state)  version  of  the  protocol. 
Mury?  can  only  guarantee  correctness  of  the  down-scaled 
version  of  the  protocol,  but  not  that  of  the  general  protocol. 
For  example,  in  modelling  our  authentication  protocol,  the 
numbers  of  mobile  nodes  and  authentication  servers  were 
scalable  and  defined  by  constants. 

The  desired  properties  of  a  protocol  can  be  specified  in 
Mun^  by  invariants ,  which  are  boolean  conditions  that  have 
to  be  true  in  every  reachable  state.  If  a  state  is  reached  in 
which  some  invariant  is  violated,  Munp  prints  an  error  trace 
-  a  sequence  of  states  from  the  start  state  to  the  state  exhibit¬ 
ing  the  problem. 

5.2  The  Methodology 

We  analyzed  our  protocol  using  the  following  sequence 
of  steps: 

1.  Formulate  the  protocol  This  generally  involves  sim¬ 
plifying  the  protocol  by  identifying  the  key  steps  and 
primitives.  The  Murcp  formulation  of  a  protocol,  how¬ 
ever,  is  more  detailed  than  the  high-level  descriptions 
often  seen  in  the  literature,  since  one  has  to  decide  ex¬ 
actly  which  messages  will  be  accepted  by  each  partic¬ 
ipant  in  the  protocol.  Since  Munp  communication  is 
based  on  shared  variables,  it  is  also  necessary  to  define 
an  explicit  message  format,  as  a  Munp  type. 

2.  Add  an  adversary  to  the  system.  We  assume  that  the 
adversary  (or  intruder)  can  masquerade  as  an  honest 
participant  in  the  system,  capable  of  initiating  commu¬ 
nication  with  a  truly  honest  participant,  for  example. 
We  also  assume  that  the  network  is  under  the  control 
of  the  adversary  and  allow  the  adversary  the  following 
actions: 

•  overhear  every  message,  remember  all  parts  of 


each  message,  and  decrypt  ciphertext  when  it  has 
the  key; 

*  intercept  (delete)  messages; 

•  generate  messages  using  any  combination  of  ini- 
tial  knowledge  about  the  system  and  parts  of 
overheard  messages. 

Although  it  is  simplest  to  formulate  an  adversary  that 
nondeterministically  chooses  between  all  possible  ac¬ 
tions  at  every  step  of  the  protocol,  it  is  more  efficient  to 
reduce  the  choices  to  those  that  actually  have  a  chance 
of  affecting  other  participants. 

3.  State  the  desired  correctness  conditions.  A  typical  cor¬ 
rectness  condition  would  be  that  the  intruder  does  not 
learn  any  secret  information.  More  details  about  the 
correctness  conditions  for  our  protocol  are  given  in 
Section  5.4. 

4,  Run  the  protocol  for  some  specific  choice  of  system 
size  parameters.  We  have  been  able  to  run  our  protocol 
with  upto  3  mobile  nodes  and  3  authentication  servers, 
where  each  mobile  node  can  execute  2  sessions  in  par¬ 
allel.  Details  of  execution  time  appear  in  Section  5.4. 

5.3  The  Intruder  Model 

The  Mur^?  intruder  model  is  limited  in  its  capabilities 
and  does  not  have  ail  the  power  that  a  real-life  intruder  may 
have.  In  particular: 

•  No  cryptanalysis .  Our  intruder  ignores  both  com¬ 
putational  and  number-theoretic  properties  of  crypto¬ 
graphic  functions.  As  a  result,  it  cannot  perform  any 
cryptanalysis  whatsoever.  If  it  has  the  proper  key,  it 
can  read  an  encrypted  message  or  (forge  a  signature). 
Otherwise,  the  only  action  it  can  perform  is  to  store  the 
message  for  a  later  replay. 

•  No  probabilities .  Mur<p  has  no  notion  of  probability. 
Therefore,  we  do  not  model  “propagation”  of  attack 
probabilities  through  our  finite-state  system  (e.g.,  how 
the  probabilities  of  breaking  the  encryption,  forging 
the  signature,  etc.  accumulate  as  the  protocol  pro¬ 
gresses).  We  also  ignore,  e.g.,  that  the  intruder  may 
learn  some  probabilistic  information  about  the  partici¬ 
pants’  keys  by  observing  multiple  runs  of  the  protocol. 

•  No  partial  information .  Keys,  signatures,  etc.  are 
treated  as  atomic  entities  in  our  model.  Our  intruder 
cannot  break  such  data  into  separate  bits.  It  also  can¬ 
not  perform  an  attack  that  results  in  the  partial  recovery 
of  a  secret  (e.g.,  half  of  the  secret  bits). 


In  spite  of  the  above  limitations,  previous  studies  have 
shown  that  Mur  ip  is  a  useful  tool  for  analyzing  security  pro¬ 
tocols.  It  considers  the  protocol  at  a  high  level  and  helps  dis¬ 
cover  a  certain  class  of  bugs  that  do  not  involve  attacks  on 
cryptographic  functions  employed  in  the  protocol.  Munp  is 
quite  useful  in  discovering  authentication  bugs  since  proper¬ 
ties  like  key  ownership,  source  of  messages,  etc.  are  easily 
captured  in  logical  statements.  The  fact  that  Mure?  did  not 
uncover  any  bugs  in  our  protocol  therefore  gives  us  a  fair 
degree  of  confidence  in  its  correctness. 

5,4  Modelling  the  Initialization  Phase 

The  Munp  model  of  the  protocol  consists  of  three  types 
of  finite  state  machines  corresponding  to  mobile  nodes,  au¬ 
thentication  servers  and  intruders.  The  number  of  mobile 
nodes,  authentication  servers  and  intruders  are  scalable  and 
defined  by  constants.  Each  mobile  node  can  participate  in  a 
number  of  parallel  sessions.  This  number  can  also  be  con¬ 
figured  by  changing  the  value  of  a  constant. 

The  state  of  a  mobile  node  consists  of  an  IP  address,  the 
IP  address  of  an  authentication  server,  the  secret  shared  with 
the  authentication  server  and  the  individual  states  of  all  the 
sessions  that  she  is  involved  in.  We  associate  the  state-id  of 
a  session  with  the  next  message  that  the  node  is  expecting 
in  that  session.  We  denote  by  S*  the  state  in  which  a  node 
is  expecting  the  ith  message  of  the  protocol.  For  example, 
after  initiating  a  session  (sending  message  1),  a  node  sets 
the  state-id  of  that  session  to  S4  since  the  next  message  that 
it  expects  is  the  4th  message  of  the  protocol.  Initially,  the 
state-ids  of  all  sessions  are  set  to  Si.  In  this  state,  a  mo¬ 
bile  node  can  spontaneously  initiate  a  session.  Other  than 
the  state-id,  the  state  of  a  session  also  includes  the  values 
of  all  the  session  parameters  that  the  mobile  node  has  seen 
up  until  that  point.  For  example,  if  the  state-id  of  a  ses¬ 
sion  that  a  mobile  node  is  taking  part  in  is  S4,  then  the  state 
would  also  contain  the  node’s  Diffie-Hellman  private  key 
and  the  address  of  the  peer  node  with  whom  she  is  exe¬ 
cuting  the  session.  Upon  completing  a  session,  the  state-id 
for  that  session  is  set  to  Sdone *  The  transition  rules  for 
a  mobile  node  capture  the  exact  sequence  of  actions  that 
she  would  carry  out  in  an  actual  run  of  the  protocol.  For 
example,  when  a  mobile  node  receives  the  4th  message  of 
the  protocol,  she  processes  it  iff  the  corresponding  state-id 
is  54.  She  then  verifies  that  the  encryption  key  specified 
in  the  message  is  the  same  as  the  key  she  shares  with  her 
authentication  server.  This  corresponds  to  decrypting  the 
message.  Then  she  computes  the  Diffie-Hellman  secret  us¬ 
ing  the  Diffie-Hellman  exponential  in  the  message  and  her 
own  previously  recorded  Diffie-Hellman  private  key.  She 
finally  verifies  that  the  computed  secret  matches  the  one  in 
the  message  before  changing  the  state-id  to  Sdone- 
The  finite  state  machine  of  an  authentication  server  is 


much  simpler.  Since  an  authentication  server  only  forwards 
messages,  her  state  does  not  change  during  the  execution  of 
the  protocol.  The  state  of  an  authentication  server  consists 
of  her  certificate,  the  verification  key  of  the  trusted  third 
party  (Certification  Authority  of  the  PKI)  and  the  shared 
keys  with  the  mobile  nodes  in  her  domain.  The  transition 
rules  define  the  sequence  of  actions  that  an  authentication 
server  executes  upon  receiving  the  2nd  or  3rd  message  of 
the  protocol. 

As  mentioned  before,  the  intruder’s  transition  rules  en¬ 
able  it  to  intercept  messages,  overhear  all  messages  and  re¬ 
member  parts  of  all  overheard  messages  and  generate  new 
messages  using  any  combination  of  initial  knowledge  and 
parts  of  overheard  messages.  Thus,  at  any  given  point  in 
the  protocol,  there  are  a  large  number  of  possible  transi¬ 
tions  for  the  intruder.  This  results  in  a  very  large  number 
of  reachable  states  for  the  protocol.  The  following  tech¬ 
niques  proved  useful  in  reducing  the  number  of  states  to  be 
explored: 

•  The  intruder  always  intercepts  all  messages  sent  by  the 
honest  participants. 

•  The  intruder  does  not  send  messages  to  honest  partici¬ 
pants  in  states  where  at  least  one  of  the  honest  partici¬ 
pants  is  able  to  send  a  message. 

•  The  intruder  only  generates  messages  that  are  expected 
by  the  legitimate  parties  and  that  can  be  meaningfully 
interpreted  by  them  in  their  current  state,  e.g.,  the  in¬ 
truder  sends  the  4th  message  to  a  mobile  node  only  if 
the  mobile  node  is  in  state  S4, 

The  first  two  techniques  have  been  proved  to  be  sound  (see 
[30]),  i.e.,  each  protocol  error  that  would  have  been  discov¬ 
ered  in  the  original  state  graph  will  still  be  discovered  in  the 
reduced  state  graph.  The  soundness  of  the  third  technique 
is  quite  obvious. 

We  modelled  the  following  correctness  conditions  in  our 
Mixrp  code: 

•  If  two  mobile  nodes  have  completed  a  session  with 
each  other,  then  the  shared  Diffie-Hellman  secret  com¬ 
puted  by  both  must  be  identical. 

•  The  secret  shared  between  two  mobile  nodes  is  not  in 
the  intruder’s  database  of  known  message  components. 

•  The  mobile  nodes  agree  on  each  other’s  identity  and 
protocol  completion  status,  i.e.,  if  A  has  completed  a 
session  with  B,  then  B  should  also  have  completed  the 
same  session  with  A  or  B  should  be  waiting  for  the  5th 
message  of  the  protocol. 

Murp  did  not  discover  any  violations  of  the  above 
mentioned  correctness  conditions  for  the  configurations  on 


which  we  ran  the  verifier.  Running  under  Linux  on  a  300 
MHz  dual-processor  Pentium  II  with  512MB  of  RAM,  the 
verifier  required  approximately  30  seconds  to  check  for  the 
case  with  2  mobile  nodes,  2  authentication  servers  and  no 
more  than  2  simultaneous  sessions  per  mobile  node.  About 
4200  states  were  explored.  The  largest  instance  of  our 
model  that  we  verified  included  3  mobile  nodes,  3  authen¬ 
tication  servers  and  no  more  than  2  simultaneous  sessions 
per  mobile  node.  Checking  took  about  20  minutes,  with 
125,941  states  explored. 

We  note  here  that  this  is  the  first  Diffie-Hellman  key  ex¬ 
change  based  protocol  that  has  been  modelled  using  Mur*p. 
Modelling  the  DH-protocol  within  the  finite  state  analy¬ 
sis  framework  required  some  thought.  The  “obvious”  ap¬ 
proach  would  be  to  do  what  is  actually  done  in  practice:  use 
integers  to  explicitly  model  the  various  parameters  (gt  pf 
x,  y)  and  then  derive  the  secret  by  exponentiating  modulo 
p.  However,  we  observe  that  explicit  exponentiation  is  un¬ 
necessary.  The  two  main  properties  that  the  model  should 
capture  are:  (a)  the  computational  hardness  of  the  Diffie- 
Hellman  problem,  i.e.,  given  gx  mod  p  and  gy  mod  p,  it 
should  not  be  possible  to  compute  gxy  mod  p;  (b)  the  com¬ 
mutativity  of  exponentiation  so  that  (gx  mod  p)y  mod  p  — 
(gy  mod  pf  modp,  (From  Fermat’s  Little  Theorem,  we 
also  know  that  both  these  values  are  equal  to  gxymod (p-1) 
mod  p.  In  order  to  capture  these  two  properties  we  used  a 
different  technique.  In  the  Munp  code,  a  key  is  modelled 
as  a  record  with  two  fields  -  a  type  and  a  random  value . 
We  defined  three  additional  types  of  keys:  dh-private ,  dh - 
public ,  and  dh-secret .  x  is  of  type  dh-private  and  gx  is  of 
type  dh-public.  For  both  keys,  the  value  is  x.  The  DH  se¬ 
cret  is  computed  using  a  function  which  takes  in  a  key  of 
type  dh-private  (say  with  value  x)  and  another  of  type  dh- 
public  (say  with  value  y)  and  returns  a  key  with  type  dh- 
secret  and  value  xy  mod  (p  —  1).  Note  that  interchanging 
the  values  of  x  and  y  yields  the  same  secret  because  of  the 
commutativity  of  integer  multiplication.  This  ensures  that 
both  participants  compute  the  same  Diffie-Hellman  secret. 
Also,  since  this  function  is  the  only  way  of  computing  a  DH 
secret,  property  (a)  above  is  also  satisfied. 

In  earlier  work  [29],  Meadows  analysed  a  Diffie- 
Hellman  based  key  exchange  protocol  using  the  NRL  Proto¬ 
col  Analyzer.  Her  framework  requires  all  assumed  crypto¬ 
graphic  identities  to  be  explicitly  specified  as  rewrite  rules. 
The  commutative  properties  of  the  Diffie-Hellman  algo¬ 
rithm  therefore  had  to  be  specified  as  such.  Her  solution  in¬ 
volved  developing  two  sets  of  operations  and  rewrite  rules, 
one  for  initiator  and  one  for  responder.  In  other  words,  com¬ 
putation  of  the  Diffie-Hellman  key  was  assumed  to  involve 
different  operations  for  initiator  and  responder,  even  though 
in  fact  they  are  both  the  same.  Two  more  rewrite  rules  were 
then  used  to  reduce  the  keys  computed  by  the  initiator  and 
the  responder  to  the  same  syntactic  expression.  The  com- 


putational  hardness  property  did  not  have  to  be  explicitly 
modelled.  The  very  fact  that  there  was  no  rewrite  rule  for 
computing  the  Diffie-Hellman  secret  from  the  public  expo¬ 
nentials  ensured  that  it  could  be  done. 

We  note  that  our  modelling  approach  is  distinct  from 
Meadows’.  Since  the  basic  modelling  frameworks  are  quite 
different,  a  direct  comparison  of  the  relative  merits  and  de¬ 
merits  of  the  two  approaches  is  not  meaningful. 

6.  Preventing  Denial-of-Service  Attacks 

The  basic  5-message  protocol  is  susceptible  to  denial  of 
service  attacks.  By  sending  a  random  number  to  a  CN,  an 
attacker  can  force  a  CN  to  perform  a  Diffie-Hellman  expo¬ 
nentiation  and  an  encryption  operation.  The  CN  will  also 
create  state  at  this  point.  By  continuously  initiating  ses¬ 
sions  with  a  CN,  an  attacker  can  exhaust  its  computation 
and  memory  resources.  One  way  of  preventing  this  attack 
would  be  to  use  “cookies”,  a  technique  originally  proposed 
by  Kara  and  Simpson  in  [31].  Upon  receiving  the  first  mes¬ 
sage,  CN  replies  with  a  cookie  (which  could  be  a  keyed 
hash  of  the  received  exponential  concatenated  with  a  times¬ 
tamp  and  the  IP  address  of  the  sender  as  used  in  the  IKE- 
SIGMA  protocol  [32]).  The  sender  then  sends  the  cookie 
back  to  CN  proving  that  it  is  capable  of  receiving  messages 
at  the  IP  address  it  is  claiming  as  its  own.  Thus,  two  addi¬ 
tional  messages  are  exchanged  between  MN  and  CN  after 
the  first  message  of  the  original  protocol. 

A  useful  property  of  our  protocol  is  that  since  authenti¬ 
cation  servers  do  not  create  state,  memory  denial  of  service 
attacks  are  not  possible  on  the  authentication  servers.  Pre¬ 
venting  computation  denial  of  service  attacks  on  the  authen¬ 
tication  servers  reduces  to  the  problem  of  detecting,  without 
performing  expensive  computations,  whether  a  message  has 
been  replayed.  Replay  attacks  on  Acn  can  be  prevented 
by  including  a  sequence  number  or  timestamp  inside  the 
encryption  in  message  2  of  the  protocol.  Acn  will  ac¬ 
cept  a  message  from  CN  only  if  the  sequence  number  is 
greater  than  the  last  sequence  number  received  from  the 
same  CN.  Preventing  denial  of  service  attacks  on  Amn 
without  adding  extra  messages,  appears  to  be  more  difficult. 
Adding  a  sequence  number  to  message  3  and  including  it  in 
the  signature  alleviates  the  problem  somewhat:  a  replayed 
message  will  be  detected  after  performing  one  public  key 
operation  instead  of  two.  Adding  two  extra  messages  for 
exchanging  cookies,  of  course,  solves  the  problem. 

7.  Conclusions 

In  response  to  the  requirement  that  all  location  informa¬ 
tion  about  a  mobile  node  in  IPv6  should  be  authenticated  [2, 
3.1],  we  have  proposed  a  protocol  for  authenticating  bind¬ 
ing  updates.  The  computational  load  on  the  mobile  nodes  is 


minimized,  by  moving  expensive  public-key  operations  to 
more  powerful  nodes.  The  number  of  messages  is  kept  at 
a  minimum.  The  appropriate  extensions  preventing  denial- 
of-service  attacks  are  also  suggested. 

We  have  formally  verified  the  correctness  of  the  proto¬ 
col  using  the  finite-state  analysis  tool  Murcp.  The  fact  that 
the  Murc^  analysis  did  not  uncover  any  bugs  gives  us  in¬ 
creased  confidence  in  the  correctness  of  the  protocol.  In 
previous  work,  Mur^  has  been  used  to  analyze  the  security 
properties  of  several  protocols.  However,  this  is  the  first 
Diffie-Hellman  based  key  exchange  protocol  that  has  been 
analyzed  with  Mury>.  We  used  a  new  modelling  technique 
to  capture  the  two  most  important  properties  of  the  Diffie- 
Hellman  exchange:  the  computational  hardness  property 
which  ensures  that  an  intruder  is  not  able  to  compute  the  DH 
secret  from  the  public  exponentials;  and  the  commutativity 
property  which  guarantees  that  both  participants  compute 
the  same  shared  secret.  Although,  in  previous  work  [29],  a 
Diffie-Hellman  based  key  exchange  protocol  has  been  for¬ 
mally  analyzed,  the  framework  and  modelling  technique 
used  there  is  quite  different  from  ours. 

Finally,  we  have  addressed  the  most  difficult  adoption  is¬ 
sue  for  authenticated  Mobile  IPv6:  reliance  on  authentica¬ 
tion  infrastructure.  Our  goal  has  been  to  make  the  best  use 
of  whatever  authentication  infrastructure  is  present,  thereby 
offering  a  middle  path  between  proposed  protocols  which 
require  the  existence  of  a  global  PKI  [2]  and  which  do  not 
assume  any  infrastructure  at  all  [1]  and  therefore  provide 
weak  authentication  guarantees.  By  capturing  the  differ¬ 
ences  in  authentication  infrastructure  in  the  type  of  public- 
key  certificates,  we  ensure  that  the  structure  of  the  protocol 
depends  minimally  on  the  available  infrastructure.  Also,  the 
update  phase  of  our  protocol  remains  the  same  in  each  case 
since  the  basis  for  authenticated  update  is  the  shared  secret 
established  in  the  initialization  phase.  We  believe  that  our 
protocol  addresses  the  main  issues  in  Mobile  IPv6  authenti¬ 
cation.  In  particular,  the  exchange  of  self-signed  certificates 
by  authentication  servers  the  first  time  these  servers  partic¬ 
ipate  in  Mobile  IP,  allows  the  protocol  to  be  used  without  a 
global  PH. 
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